Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@docs/dashpay/research/01-dip-spec.md`:
- Line 131: Several fenced code blocks use plain ``` without a language tag;
update each triple-backtick fence in the document (e.g., the blocks currently
shown as ``` at the indicated locations) to include an explicit language token
(for non-code or prose use `text`, or a specific language like `json`, `bash`,
`markdown` where applicable) so the markdown linter passes; search for all
occurrences of ``` (including the ones noted around 131, 194, 245, 289, 418,
455) and replace them with ```text or the appropriate language identifier.

In `@docs/dashpay/research/02-rust-dashcore-keywallet.md`:
- Line 232: The markdown contains fenced code blocks without language tags;
update the offending triple-backtick fences to include the appropriate language
identifier (e.g., ```rust, ```bash, or ```text) for the code snippets so
markdownlint passes and syntax highlighting works—locate the plain ``` fences in
the document (the blocks referenced in the review) and replace them with
language-tagged fences.

In `@docs/dashpay/research/05-swift-app.md`:
- Line 47: The fenced code block currently uses a bare triple-backtick fence
(```); add a language tag (e.g., ```swift or ```text) immediately after the
opening backticks to satisfy markdownlint and enable proper syntax highlighting
for that block.

In `@docs/dashpay/research/06-interop-desk-check.md`:
- Line 366: The fenced code block uses plain ``` without a language tag; update
the opening fence to include an appropriate language identifier (for example
`http`, `text`, or `bash`) so markdownlint is satisfied and readability
improves—locate the triple-backtick fenced block in the document and add the
language tag immediately after the opening ``` fence.
- Line 24: The table row contains an extra leading column ("2") so it has four
columns while the table header defines three; remove the extra column in the row
that contains "2" (the row with "ECDH shared-key derivation" and the
libsecp256k1 SHA256 expression) so the row matches the 3-column header layout,
keeping the description "ECDH shared-key derivation" and the verdict "**PASS** —
all three stacks compute libsecp256k1-style `SHA256((y[31]&0x1|0x2) ‖ x)`" as
the remaining columns.

In `@docs/dashpay/SPEC.md`:
- Line 111: Several fenced code blocks in SPEC.md are missing language
identifiers; update each triple-backtick fence (``` ) at the noted examples so
they include an appropriate language tag (e.g., change ``` to ```text, ```rust,
or ```swift as appropriate) to satisfy markdownlint and enable correct syntax
highlighting; search for the bare ``` occurrences (including the ones referenced
near the examples) and replace them with language-tagged fences, ensuring
opening and closing fences remain paired.

In `@packages/rs-platform-wallet/src/manager/dashpay_sync.rs`:
- Around line 221-223: The background loop cleanup currently unconditionally
sets this.background_cancel to None (in the block near start()), which can
overwrite a newer token if stop() and start() race; change the logic so the
background thread only clears background_cancel if the stored cancel token it
captured at spawn time still matches the current token in this.background_cancel
(i.e., capture the Arc/ID of the cancel handle when spawning and
compare-before-clearing); apply the same compare-and-clear pattern in the stop()
/ thread-exit cleanup (references: this.background_cancel, start(), stop()) so a
late-exiting old loop cannot null out a replacement token.

In `@packages/rs-platform-wallet/src/wallet/identity/network/contact_requests.rs`:
- Around line 103-118: The sender/recipient key selection currently using
sender_identity.public_keys().iter().find(...) (checking Purpose::ENCRYPTION and
KeyType::ECDSA_SECP256K1) can pick a disabled/rotated key; update the logic to
only consider active/enabled keys (e.g., filter by .enabled() or reuse the
existing enabled-key selection utility used for signing) so
sender_encryption_key and recipient_key_index (the call to
select_recipient_key_index should be updated similarly or replaced) always
reference the current active ENCRYPTION/DECRYPTION ECDSA_SECP256K1 key; ensure
you still call .map(...).ok_or_else(...) and preserve error type
PlatformWalletError::InvalidIdentityData when no active key is found.
- Around line 516-556: collect_account_build_candidates currently skips contacts
when info.core_wallet.accounts.dashpay_external_accounts.contains_key(&key) is
true, which prevents retries if register_contact_account previously failed after
inserting an external entry; remove that gating so contacts with an
incoming_request (incoming.encrypted_public_key and key indices) are always
returned as AccountBuildCandidate (unless payment_channel_broken) to allow
build_contact_accounts -> register_contact_account to retry; specifically, in
collect_account_build_candidates remove or change the has_external
check/continue and rely on contact.incoming_request and payment_channel_broken
to decide inclusion (keep AccountBuildCandidate fields: contact_id,
encrypted_public_key, our_decryption_key_index, contact_encryption_key_index).
- Around line 452-509: parse_contact_request_doc currently only extracts
required fields and drops optional fields encryptedAccountLabel and
autoAcceptProof, causing restores to lose these values; update
parse_contact_request_doc (and thus parse_sent_contact_request_doc which calls
it) to also read props.get("encryptedAccountLabel").and_then(|v: &Value|
v.as_str()).map(|s| s.to_owned()) and props.get("autoAcceptProof").and_then(|v:
&Value| v.as_bytes()).cloned() (or appropriate conversions) and pass them into
ContactRequest::new (or the appropriate constructor/factory) so the
ContactRequest created preserves encryptedAccountLabel and autoAcceptProof
during ingest/reconcile. Ensure the match arm pattern includes these Option
values and the fallback logging remains unchanged.

In
`@packages/rs-platform-wallet/src/wallet/identity/state/managed_identity/contact_requests.rs`:
- Around line 116-130: The code removes an incoming request from
self.incoming_contact_requests but the returned ContactChangeSet only records
cs.rejected, so on replay the incoming entry isn't removed; update the change
set returned by the function to also include the incoming-removal for (owner_id,
*sender_id, account_reference) (i.e., add the corresponding removal entry to the
ContactChangeSet alongside cs.rejected) so that replay will delete the
incoming_contact_requests entry when applying the rejection tombstone.

---

Outside diff comments:
In `@packages/rs-platform-wallet/src/wallet/identity/network/contact_requests.rs`:
- Around line 806-875: The local-only already_reciprocated check (variable
already_reciprocated) can be stale; change the flow so before attempting
send_contact_request_with_external_signer you either (A) perform a platform
check for an existing reciprocal contact request/relationship (use whatever
network client/query you have for checking platform contact requests for
(ownerId,toUserId,accountReference)) and set already_reciprocated accordingly,
or (B) keep the existing local check but add a duplicate-send fallback: catch
the unique-index conflict/error returned by
send_contact_request_with_external_signer and, on that specific error, log that
the reciprocal exists on Platform and run the adopt path (call
register_contact_account(&our_identity_id, &sender_id, 0) and treat as success).
Reference already_reciprocated, send_contact_request_with_external_signer, and
register_contact_account when implementing either fix.

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `packages/rs-platform-wallet-storage/migrations/V001__initial.rs`:
- [BLOCKING] packages/rs-platform-wallet-storage/migrations/V001__initial.rs:186-213: V001 migration edited in-place violates append-only policy and breaks upgrade from v4.0.0-beta.4
  This PR adds `contacts.payment_channel_broken` and a new `rejected_contact_requests` table by editing V001 directly. V001 (without these additions) was already shipped in `v4.0.0-beta.4` (commit da9d3fe84e / schema confirmed via `git show`), and `packages/rs-platform-wallet-storage/README.md:106` explicitly states migrations are append-only and applied by refinery on every `open`. refinery checksums each migration in `refinery_schema_history`; against an existing v4.0.0-beta.4 DB it will either abort with a divergent-checksum error or silently skip V001 (already applied) — in which case neither the new table nor the new column is ever created, and the first runtime write in `contacts.rs:240` (`INSERT INTO rejected_contact_requests …`) or `contacts.rs:194-212` (`payment_channel_broken` column) fails at the SQLite layer. `tc029_migration_fingerprint_stable` does not catch this because it only checks self-stability, not a pinned hash. Add `V002__dashpay_reject_and_broken_channel.rs` doing `ALTER TABLE contacts ADD COLUMN payment_channel_broken INTEGER` and `CREATE TABLE rejected_contact_requests (…)`; the loader at `contacts.rs::load_state` already tolerates NULL `payment_channel_broken`, so a default-less ALTER is compatible.

In `packages/rs-platform-wallet/src/wallet/identity/state/managed_identity/contact_requests.rs`:
- [BLOCKING] packages/rs-platform-wallet/src/wallet/identity/state/managed_identity/contact_requests.rs:109-131: `record_rejected_contact_request` removes incoming in memory but does not emit `removed_incoming`
  The function calls `self.incoming_contact_requests.remove(sender_id)` and returns a `ContactChangeSet` populated only with `cs.rejected`. The unified-`contacts`-table writer at `rs-platform-wallet-storage/src/sqlite/schema/contacts.rs:182-193` only `DELETE`s when `cs.removed_incoming` is non-empty, so the previously persisted state='received' row (with the `incoming_request` blob) stays in SQLite. Once `persister.load()` (TODO at `sqlite/persister.rs:909`) is wired up, the unified contacts reader rebuckets that row as an incoming request, `apply_changeset` re-inserts it into `incoming_contact_requests`, and the FFI surfaces the explicitly-rejected request back to the UI. The persisted delta is also internally inconsistent with the in-memory mutation — a delta-persistence invariant violation. The in-memory `rejected_tombstone_round_trips_and_respects_account_reference` test does not catch this because it round-trips via `apply_changeset`, not the SQLite reader. Fix by also inserting a matching `ReceivedContactRequestKey { owner_id, sender_id: *sender_id }` into `cs.removed_incoming`.

In `packages/rs-platform-wallet-storage/src/sqlite/schema/identities.rs`:
- [BLOCKING] packages/rs-platform-wallet-storage/src/sqlite/schema/identities.rs:206-222: `rejected_contact_requests` is written but never read — tombstones lost across restart
  The PR adds a writer (`contacts.rs:240`), a migration row (`V001__initial.rs:203`), and an `apply_changeset` branch that restores `ManagedIdentity.rejected_contact_requests` from `cs.rejected`. But `managed_identity_from_entry` hard-codes `rejected_contact_requests: Default::default()` (line 214), and grep confirms no `load_state` reader for the new table. Once `persister.load()` (TODO at `sqlite/persister.rs:909`) is wired up, the in-memory tombstone map is always empty after restart even though SQLite holds the rows. `is_request_rejected` then returns `false`, the sweep's tombstone-skip in `network/contact_requests.rs:396-404` does not fire, and the recurring DashPay loop (G12) resurrects every rejected request on the first sweep — exactly the M1 failure mode the SPEC.md cites as the reason G5 must land with G12. Add a per-wallet `load_state` for `rejected_contact_requests` and route its output into the `ContactChangeSet.rejected` synthesized during rehydration.

In `packages/rs-platform-wallet/src/wallet/identity/network/contact_requests.rs`:
- [BLOCKING] packages/rs-platform-wallet/src/wallet/identity/network/contact_requests.rs:711-728: Transient identity fetch failures inside account-build are marked as permanent
  `build_contact_accounts` treats any error from `register_external_contact_account` as permanent and calls `mark_contact_channel_broken`. But `register_external_contact_account` (`network/contacts.rs:400-407`) performs another `Identity::fetch` for the same contact and wraps the DAPI/network error as `PlatformWalletError::InvalidIdentityData`. A transient DAPI hiccup after validation therefore permanently disables the payment channel; subsequent sweeps skip the contact via the `payment_channel_broken` filter at line 530, and recovery only fires if a superseding contactRequest happens to arrive — contradicting the policy in the docstring at lines 573-578 ("Transient (identity fetch / network): logged, left for the next sweep to retry. The broken flag stays clear."). The fix is to perform the contact-identity fetch and treat its failure as transient *before* calling `register_external_contact_account` (mirroring the existing fetch at lines 631-655) and to scope the permanent-broken classification to genuinely non-recoverable failures (decrypt/decode, missing-key, key-type mismatch).
- [BLOCKING] packages/rs-platform-wallet/src/wallet/identity/network/contact_requests.rs:383-392: Superseding requests from established contacts are skipped — `payment_channel_broken` recovery is unreachable
  The received-side ingest drops every doc whose sender is already in `established_contacts` before consulting `accountReference`. `EstablishedContact::reestablish_preserving_metadata` exists precisely to clear `payment_channel_broken = false` when a fresh request flows in (see `types/dashpay/established_contact.rs:84-104`), and `collect_account_build_candidates` documents the recovery contract at lines 528-529 ("never retry a permanently-broken channel — wait for a superseding request (which clears the flag on re-establish)"). But there is no path that reaches `reestablish_preserving_metadata` for an already-established sender from the sync sweep — `add_incoming_contact_request` is only called for new senders here, and the send-side guard at `state/managed_identity/contact_requests.rs:46-48` similarly returns early for established contacts. Net effect: once `payment_channel_broken` is set, it stays set forever. Either (a) detect a superseding incoming request (new `accountReference` for the same sender) and route it through the reestablish path, or (b) change the broken-channel policy so the next sweep can retry under controlled conditions.
- [SUGGESTION] packages/rs-platform-wallet/src/wallet/identity/network/contact_requests.rs:5733-5749: `select_recipient_key_index` returns disabled keys
  The send-side recipient-key selector iterates `recipient_identity.public_keys()` and returns the first key whose purpose is DECRYPTION (then ENCRYPTION) and whose type is ECDSA_SECP256K1, with no `disabled_at` check. `validate_contact_request` in `crypto/validation.rs` does gate on disabled keys, so if a preferred DECRYPTION key has been rotated/disabled this selector returns it anyway and the broadcast fails downstream with an opaque error instead of falling through to a usable ENCRYPTION key on the same identity. Add `&& k.disabled_at().is_none()` to both branches so selection is consistent with validation.

In `packages/rs-platform-wallet/src/wallet/identity/crypto/validation.rs`:
- [BLOCKING] packages/rs-platform-wallet/src/wallet/identity/crypto/validation.rs:50-62: `purpose_mismatch` is set even when a non-purpose hard error is also present
  The docstring at lines 19-29 contracts `purpose_mismatch` as `true` *only* when the sole reason for invalidity is a key-purpose mismatch — it is what tells `build_contact_accounts` at `network/contact_requests.rs:689` to treat the failure as a non-permanent skip instead of marking the channel permanently broken. The implementation does not preserve that invariant: `add_purpose_error` unconditionally sets `purpose_mismatch = true`, and `add_error` never clears it. A request whose key has both a wrong key type (hard, permanent error) and a wrong purpose ends up with `is_valid = false, purpose_mismatch = true`, and the caller skips + retries forever instead of marking broken. The mobile testnet census makes this rare in practice today, but the classifier is the load-bearing primitive the recovery policy is built on — fix `add_error` to clear the flag, and fix `add_purpose_error` to only set it if no prior hard error was recorded.

In `packages/rs-platform-wallet/src/manager/dashpay_sync.rs`:
- [SUGGESTION] packages/rs-platform-wallet/src/manager/dashpay_sync.rs:192-227: `stop()` followed quickly by `start()` can let the old thread null out the new cancel token
  `stop()` takes the current `background_cancel`, sets it to `None`, then cancels the old token. The spawned thread exits its loop on cancellation and at lines 221-223 re-acquires the guard and writes `*guard = None`. If `start()` runs between `stop()` and the old thread's cleanup block, the old thread's final clear will overwrite the new token just installed by `start()` — leaving `background_cancel` empty while a fresh sync thread is still running, so a subsequent `stop()`/`quiesce()` will be a no-op against that running thread. The normal shutdown path (`quiesce` waits for in-flight passes) does not hit this, but bare `stop()`/`start()` races can. Fix by capturing the token at spawn time and only clearing the guard if it still holds that same token (`if matches!(*guard, Some(t) if Arc::ptr_eq(...)) { *guard = None; }`).

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In
`@packages/swift-sdk/Sources/SwiftDashSDK/PlatformWallet/PlatformWalletPersistenceHandler.swift`:
- Around line 1919-1925: persistDashpayPayments is swallowing failures from
backgroundContext.save() via try?, which can silently drop payment-history
updates; change the save to propagate or log errors instead of ignoring them:
replace the try? backgroundContext.save() with a throwing or do/catch path
inside persistDashpayPayments that captures the thrown error from
backgroundContext.save(), records telemetry/logging (or rethrows to the caller)
with context (e.g., include which payment batch or wallet ID), and preserve the
existing inChangeset check (if !self.inChangeset) so the save still only runs
when appropriate; update callers or function signature as needed to handle
propagated errors or ensure telemetry is emitted in the catch.

In
`@packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Views/DashPay/DashPayTabView.swift`:
- Around line 35-40: The optimisticSentIds and ownProfile state are
identity-scoped but currently persist across identity switches; update the
activeIdentity handling (the Task that observes activeIdentity) to reset
identity-scoped UI state at the start of the task: clear optimisticSentIds and
set ownProfile to nil (or otherwise remove cached profile) before loading;
alternatively refactor optimisticSentIds and ownProfile to be keyed by owner
identity (e.g., a dictionary keyed by activeIdentity.id) and read/write via that
key, and ensure loadOwnProfileFromCache() does not retain the previous profile
on read failure for the new identity but returns nil so the UI doesn’t show the
old identity’s data.

In
`@packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Views/IdentityDetailView.swift`:
- Around line 1235-1243: The avatar downloader currently accepts any parseable
URL, allowing non-HTTPS schemes; update fetchAvatarBytes to explicitly validate
the URL scheme and reject anything not exactly "https" before creating the
URLRequest, returning an error (or nil) for non-https inputs; locate
fetchAvatarBytes (and the analogous implementation referenced around lines
1390-1410) and add a guard that checks url.scheme?.lowercased() == "https" and
fails early with a clear error to prevent http or other schemes from being
fetched.

In
`@packages/swift-sdk/SwiftExampleApp/SwiftExampleAppUITests/DashPayTabUITests.swift`:
- Around line 92-97: Replace the immediate existence check on the toolbar
refresh button with a timed wait to avoid flakes: locate the `refresh` query
using `Identifier.refreshButton` in DashPayTabUITests (variable `refresh`) and
change the assertion to call `refresh.waitForExistence(timeout: ...)` instead of
checking `refresh.exists`, keeping the same failure message; choose a reasonable
timeout (e.g., 1–5s) consistent with other tests.

---

Nitpick comments:
In
`@packages/swift-sdk/SwiftTests/SwiftDashSDKTests/DashPayPersistenceTests.swift`:
- Around line 421-465: In testPaymentRefreshDoesNotCommitAnOpenChangesetRound,
add assertions that verify the payment row staged by persistDashpayPayments is
not visible mid-round and is rolled back after endChangeset(..., success:
false); specifically, call the existing payment-fetch helper (or add/rename a
fetch function for PersistentDashpayPayment rows) to assert count == 0
immediately after the mid-round persist and again after
handler.endChangeset(..., success: false), mirroring the contact-row assertions
so the test verifies payment atomicity as well as contact atomicity.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In
`@packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Core/Views/AccountListView.swift`:
- Around line 35-42: The visible-empty-state logic is still checking the raw
accounts collection instead of the filtered/sorted list, causing the UI to hide
the "No Accounts" state when only accountType 12/13 are present; update the
empty-state checks to use orderedAccounts.isEmpty (or introduce a
visibleAccounts computed collection that filters out accountType 12/13 and reuse
it everywhere) and replace any usages of accounts.isEmpty / !accounts.isEmpty in
AccountListView with checks against that filtered collection so the UI matches
the displayed list (keep AccountListView.sortKey as the sorting helper).

---

Outside diff comments:
In
`@packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Views/DashPay/DashPayTabView.swift`:
- Around line 23-26: The persisted AppStorage key stored in DashPayTabView
(`@AppStorage("dashpay.activeIdentityId") private var storedIdentityId`) is
global across networks; change it to be network-scoped by deriving the key from
the current network identifier (e.g., include network.rawValue or chainId) so
each network has its own stored key. Update DashPayTabView to compute the
AppStorage key at runtime (or use a computed property / wrapper that returns
"dashpay.activeIdentityId.\(networkId)") using the view’s network/environment
value and ensure storedIdentityId is read/written through that network-scoped
key so switching networks preserves separate selections.

---

Duplicate comments:
In
`@packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Views/DashPay/DashPayTabView.swift`:
- Around line 169-177: The task block keyed by .task(id:
activeIdentity?.identityId) is not resetting identity-scoped state: clear
optimisticSentIds and ownProfile immediately at the top of that task before
calling loadOwnProfileFromCache() and walletManager.dashPaySyncNow(); and update
loadOwnProfileFromCache() so that on a cache read failure for the new identity
it does not retain the previous ownProfile (set ownProfile to nil or replace
with an empty/default value) instead of keeping the old profile. Ensure the
reset refers to the existing properties optimisticSentIds and ownProfile and the
loadOwnProfileFromCache() function so the UI doesn't show the previous identity
while the new identity's cache is loaded.

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `packages/rs-platform-wallet-storage/src/sqlite/schema/identities.rs`:
- [BLOCKING] packages/rs-platform-wallet-storage/src/sqlite/schema/identities.rs:206-222: rejected_contact_requests is written but never read — tombstones lost across restart
  Verified at HEAD: managed_identity_from_entry still hard-codes rejected_contact_requests: Default::default() at line 214. The writer at contacts.rs:240 (INSERT INTO rejected_contact_requests) and migration row at V001:203 exist, but there is no load_state reader for the new table and apply_changeset only handles live deltas — restored state is always empty. The recurring DashPay loop's tombstone-skip at network/contact_requests.rs:396-404 never fires after a restart, so a rejected contact request is resurrected on the first sweep. Add a per-wallet load_state for rejected_contact_requests and route its output into the ContactChangeSet.rejected synthesized during rehydration.

In `packages/swift-sdk/Sources/SwiftDashSDK/PlatformWallet/PlatformWalletPersistenceHandler.swift`:
- [BLOCKING] packages/swift-sdk/Sources/SwiftDashSDK/PlatformWallet/PlatformWalletPersistenceHandler.swift:2980-2996: Wallet deletion omits new DashPay payment children before deleting identities — same fatal pattern as contact requests
  Verified: PersistentDashpayPayment.owner is declared as non-optional (`public var owner: PersistentIdentity`), and the new cascade relationship was added on PersistentIdentity.dashpayPayments in the M2 delta. The PHASE 1 pre-delete loop at lines 2986-2996 iterates dpnsNames, dashpayProfile, and contactRequests — but not dashpayPayments. The surrounding comment (lines 2962-2978) explicitly states this phase exists because SwiftData fatals during save() when it must null out a non-optional inverse on a child processed in the same delete batch. dashpayPayments has the exact same shape as contactRequests, so a wallet with persisted DashPay payments can crash or fail to wipe cleanly when deleted. Add a `for payment in Array(identity.dashpayPayments) { backgroundContext.delete(payment) }` loop alongside the existing pre-deletion.

In `packages/rs-platform-wallet/src/wallet/identity/network/contact_requests.rs`:
- [SUGGESTION] packages/rs-platform-wallet/src/wallet/identity/network/contact_requests.rs:245-261: select_recipient_key_index returns disabled keys
  Verified at HEAD lines 245-261: the selector iterates recipient_identity.public_keys() and returns the first DECRYPTION (then ENCRYPTION) ECDSA_SECP256K1 key with no disabled_at check. validate_contact_request in crypto/validation.rs does gate on disabled keys, so a recipient with a disabled preferred DECRYPTION key gets returned anyway and the broadcast fails downstream with an opaque error instead of falling through to a usable ENCRYPTION key on the same identity. Beyond reliability, on the send-side this also means the wallet could encrypt the DIP-15 compact xpub to a revoked key whose private half may be compromised. Add `&& k.disabled_at().is_none()` to both branches so selection matches validation.

In `packages/rs-platform-wallet-ffi/src/dashpay_payment.rs`:
- [SUGGESTION] packages/rs-platform-wallet-ffi/src/dashpay_payment.rs:89-108: DashpayPaymentFFI derives Clone, Copy despite owning *mut c_char strings reclaimed by dashpay_payment_array_free
  Verified at HEAD lines 89-108: DashpayPaymentFFI carries two heap-owned C strings (txid, memo — produced via CString::into_raw in cstring_or_null and reclaimed via CString::from_raw in dashpay_payment_array_free), yet the struct is `#[derive(Debug, Clone, Copy)]`. With Copy the compiler will silently shallow-duplicate the struct on any by-value rebinding inside this crate, and a subsequent free walk on the array (or a stray from_raw on the duplicate) would double-free the txid/memo allocations across the FFI boundary. Today's call sites are sound — the struct is built once, moved into Vec → Box<[T]> → Box::into_raw, and reclaimed exactly once — but the Copy derive removes the borrow-checker guardrail that normally prevents this class of bug at refactor time. Sibling FFI types in this crate that own heap pointers (ContactRequestFFI, WalletChangeSetFFI) deliberately omit Copy for exactly this reason. Drop Copy (and Clone if unneeded) on this struct. The cross-boundary contract is unchanged — Swift consumes by raw pointer.

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `packages/rs-platform-wallet/src/wallet/identity/state/managed_identity/contact_requests.rs`:
- [BLOCKING] packages/rs-platform-wallet/src/wallet/identity/state/managed_identity/contact_requests.rs:109-131: record_rejected_contact_request drops incoming in memory but never persists the deletion
  Verified at HEAD lines 109-131: line 116 calls `self.incoming_contact_requests.remove(sender_id)` but the returned `ContactChangeSet` (lines 127-129) only populates `cs.rejected`. The unified contacts-table writer in `rs-platform-wallet-storage/src/sqlite/schema/contacts.rs` only DELETEs incoming rows when `cs.removed_incoming` is non-empty, so the persisted `state='received'` row with its stale `incoming_request` blob stays in SQLite. Once `persister.load()` is wired up, the contacts reader re-buckets that row as an incoming request and `apply_changeset` re-inserts it — the explicitly-rejected request reappears in the UI. The in-memory mutation and the persisted delta are internally inconsistent. Emit a matching `ReceivedContactRequestKey { owner_id, sender_id: *sender_id }` into `cs.removed_incoming` alongside `cs.rejected`.

In `packages/rs-platform-wallet-storage/src/sqlite/schema/identities.rs`:
- [BLOCKING] packages/rs-platform-wallet-storage/src/sqlite/schema/identities.rs:206-222: rejected_contact_requests tombstones are written but never restored on rehydration
  Verified at HEAD: `managed_identity_from_entry` still hard-codes `rejected_contact_requests: Default::default()` at line 214. The writer at `contacts.rs:240` (`INSERT INTO rejected_contact_requests`) and the migration row at `V001:203` exist, but no `load_state` reader for the new table exists, and `apply_changeset` only handles live deltas — restored state is always empty. The recurring DashPay loop's tombstone-skip at `network/contact_requests.rs:396-404` therefore never fires after a restart, so a rejected contact request is resurrected on the first sweep and surfaces to the user again. Security framing: the on-platform document is immutable, so the local tombstone is the ONLY thing that suppresses a spammer's repeated contact request — a wipe-on-restart defeats the user's explicit reject. Add a per-wallet `load_state` reader for `rejected_contact_requests` and route its output into the `ContactChangeSet.rejected` synthesized during rehydration.

In `packages/rs-platform-wallet/src/wallet/identity/network/contact_requests.rs`:
- [BLOCKING] packages/rs-platform-wallet/src/wallet/identity/network/contact_requests.rs:711-729: Transient DAPI failures inside register_external_contact_account are classified as permanent
  Verified at HEAD lines 711-729: `build_contact_accounts` treats ANY error from `register_external_contact_account` as permanent and calls `mark_contact_channel_broken`. `register_external_contact_account` performs a fresh `Identity::fetch` internally and wraps DAPI/network failures as `PlatformWalletError::InvalidIdentityData`. A single transient DAPI hiccup therefore permanently disables the payment channel; subsequent sweeps skip the contact via the `payment_channel_broken` filter, and recovery only fires if a superseding contactRequest arrives — but the established-contact ingest skip at line 389 makes that path unreachable. Combined, a transient network event bricks a channel forever, and a malicious or unreliable DAPI endpoint becomes a persistent availability attack against payments to a specific contact. Fix by either passing the pre-fetched identity into registration or scoping permanent-broken classification to genuinely non-recoverable failures (decrypt/decode, missing-key, key-type mismatch).
- [BLOCKING] packages/rs-platform-wallet/src/wallet/identity/network/contact_requests.rs:383-404: Established-contact ingest skip makes payment_channel_broken recovery unreachable
  Verified at HEAD lines 383-404: the received-side ingest drops every doc whose sender is already in `established_contacts` (line 389) BEFORE consulting `accountReference`. `EstablishedContact::reestablish_preserving_metadata` exists precisely to clear `payment_channel_broken` when a fresh request flows in, and `collect_account_build_candidates` documents the recovery contract ("never retry a permanently-broken channel — wait for a superseding request which clears the flag on re-establish"). But no path reaches `reestablish_preserving_metadata` for an already-established sender from the sync sweep — `add_incoming_contact_request` is only called for new senders here, and the send-side guard at `state/managed_identity/contact_requests.rs:46-48` also returns early for established contacts. Once `payment_channel_broken` is set, it stays set forever. Either detect a new `accountReference` for the same sender and route through the reestablish path, or change the broken-channel policy to permit controlled retry.
- [BLOCKING] packages/rs-platform-wallet/src/wallet/identity/network/contact_requests.rs:245-261: select_recipient_key_index returns disabled (revoked) keys — DIP-15 compact xpub encrypted to a key whose private half may be compromised
  Verified at HEAD lines 245-261: the selector iterates `recipient_identity.public_keys()` and returns the first DECRYPTION (then ENCRYPTION) ECDSA_SECP256K1 key with no `disabled_at` check. `validate_contact_request` in `crypto/validation.rs` does gate on `disabled_at`, so the asymmetry creates both a reliability bug (an opaque downstream broadcast failure instead of falling through to a usable key) AND a real confidentiality exposure: on send, the wallet encrypts the 69-byte DIP-15 compact xpub (fingerprint‖chaincode‖pubkey — combined with `accountReference` lets the holder derive every receiving address on that account) to a key the recipient has explicitly revoked. Identity-key revocation is the on-platform mechanism for declaring "the private half of this key may be compromised". Add `&& k.disabled_at().is_none()` to both branches so selection matches validation. (Promoted from suggestion to blocking on the security-auditor confidentiality analysis.)

In `packages/swift-sdk/Sources/SwiftDashSDK/PlatformWallet/PlatformWalletPersistenceHandler.swift`:
- [BLOCKING] packages/swift-sdk/Sources/SwiftDashSDK/PlatformWallet/PlatformWalletPersistenceHandler.swift:3018-3035: Wallet deletion PHASE 1 omits PersistentDashpayPayment children — same fatal pattern as contactRequests
  Verified at HEAD: PHASE 1 (lines 3024-3034) iterates `dpnsNames`, `dashpayProfile`, and `contactRequests` but NOT `dashpayPayments`. `PersistentDashpayPayment.owner` is non-optional (`PersistentDashpayPayment.swift:98`), and `PersistentIdentity.dashpayPayments` is the cascading inverse added in this PR. The surrounding comment (lines 3018-3023) explicitly states this phase exists because SwiftData fatals during `save()` when it must null out a non-optional inverse on a child processed in the same batch — exactly the shape of the new payments relationship. A wallet with persisted DashPay payment history will hit the SwiftData fatal at PHASE 2 (`save()` after `delete(identity)`), aborting before the wallet row is removed. The user's belief that they wiped DashPay data is wrong, and plaintext memo + counterparty id + amount + txid rows remain on disk. Add a `for payment in Array(identity.dashpayPayments) { backgroundContext.delete(payment) }` loop alongside the existing pre-deletions.

In `packages/rs-platform-wallet/src/manager/dashpay_sync.rs`:
- [BLOCKING] packages/rs-platform-wallet/src/manager/dashpay_sync.rs:192-235: DashPaySyncManager thread cleanup unconditionally clears the cancel token — stop/start race enables use-after-free across FFI
  Verified at HEAD lines 192-235: the spawned thread's cleanup at lines 230-232 writes `*guard = None` on loop exit regardless of which token the slot currently holds. If `stop()` cancels the old token and `start()` installs a fresh token before the old thread reaches cleanup, the old thread clears the NEW token — `background_cancel` is empty while a fresh sync thread is still running. `stop()`/`quiesce()` then become a no-op against that running thread. In this PR's Swift integration the persister and DashPay event callbacks close over an UnsafePointer<Context> allocated on the Swift side; calling `dashpay_sync_manager_destroy` (or the wallet manager's drop) after the visible token was cleared frees that context while the surviving thread continues invoking the callbacks against the freed pointer — a concrete use-after-free crossing the C ABI, reachable through normal start/stop/destroy controls (toggling tabs, login/logout) and widened by attacker-influenced network timing. Capture the spawned token and only clear the slot if it still holds the same token (`Arc::ptr_eq`), mirroring `ShieldedSyncManager`'s generation guard. (Upgraded from suggestion to blocking based on the security-auditor and codex-security cross-checks of the destroy/UAF path.)

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `packages/rs-platform-wallet/src/wallet/identity/network/contact_requests.rs`:
- [BLOCKING] packages/rs-platform-wallet/src/wallet/identity/network/contact_requests.rs:165-201: Send-side rotation version lookup ignores established_contacts — re-send after auto-establishment reuses version=0 and collides on the unique index
  The new G3 rotation logic computes `previous_version` only from `managed.sent_contact_requests.get(recipient_identity_id)` (line 171). But establishment (`add_incoming_contact_request` line 175 and `apply_established_contact` line 372 in state/managed_identity/contact_requests.rs) explicitly removes the entry from `sent_contact_requests` and parks the prior outgoing request on `EstablishedContact.outgoing_request`. Once the reciprocal arrives and a sweep auto-establishes the pair, the next `send_contact_request` to that recipient sees `previous_version = None` and falls back to `version = 0`. With deterministic xpub/ECDH for the same (sender, recipient) and unchanged `account_index`, the PRF reproduces the same masked `account_reference` as the original sent request. The contract's unique index `($ownerId, toUserId, accountReference)` rejects the broadcast — the exact failure mode G3 was added to prevent. Fall back to `established_contacts[recipient].outgoing_request` (taking the max of both versions if both are present).
- [BLOCKING] packages/rs-platform-wallet/src/wallet/identity/network/contact_requests.rs:441-478: Historical contactRequest documents replay as fresh rotations every sync sweep
  The rotation guard at line 451 only compares the incoming reference against the currently tracked reference (incoming map or established contact). contactRequest documents are immutable, and `fetch_received_contact_requests(identity_id, None)` (line 370) is unfiltered, so every sweep returns both the original v=0 and any rotated v=N documents. Within a single sweep, ingesting v=0 against an already-tracked v=N flips the established contact back to v=0 and queues a teardown (lines 472-478, then 517-528), and the next document in the same iteration flips it forward again. Across sweeps the same churn replays — the external account is torn down and rebuilt on every cycle, generating wasted DAPI traffic. Worse, if the freshest document falls outside the eventual paginated window (post-M3 growth), the contact can regress to the stale xpub. Compare by `created_at`/version monotonicity, not bare reference inequality: only apply rotation when the incoming request strictly supersedes the tracked one.
- [BLOCKING] packages/rs-platform-wallet/src/wallet/identity/network/contact_requests.rs:292-308: select_recipient_key_index returns disabled (revoked) keys — DIP-15 compact xpub encrypted to a key whose private half may be compromised
  Verified at HEAD lines 292-308: the selector iterates `recipient_identity.public_keys()` and returns the first DECRYPTION (then ENCRYPTION) ECDSA_SECP256K1 key with no `disabled_at` check. `validate_contact_request` does gate on `disabled_at`, so the send/receive interop rules are asymmetric. On send, the 69-byte DIP-15 compact xpub (fingerprint‖chaincode‖pubkey — combined with `accountReference` lets the holder derive every receiving address on that account) is encrypted to a key the recipient has explicitly revoked. Identity-key revocation is the on-platform mechanism for declaring 'this key's private half may be compromised'. Add `&& k.disabled_at().is_none()` to both branches so selection matches validation.

In `packages/rs-platform-wallet-storage/src/sqlite/schema/identities.rs`:
- [BLOCKING] packages/rs-platform-wallet-storage/src/sqlite/schema/identities.rs:206-222: rejected_contact_requests tombstones are written but never restored on rehydration
  `managed_identity_from_entry` still hard-codes `rejected_contact_requests: Default::default()` at line 214. The writer at `sqlite/schema/contacts.rs:240` (INSERT INTO rejected_contact_requests) and the V001 row exist, but there is no `load_state` reader for the new table, and `apply_changeset` only handles live deltas — restored state is always empty after restart. The recurring DashPay loop's tombstone-skip at `network/contact_requests.rs:457` therefore never fires after restart, so a rejected request is resurrected on the first sweep. Because the on-platform document is immutable, wiping the tombstone on restart defeats the user's explicit reject. Add a per-wallet `load_state` reader for `rejected_contact_requests` and route its output into the rehydration changeset / ManagedIdentity field.

In `packages/swift-sdk/Sources/SwiftDashSDK/PlatformWallet/PlatformWalletPersistenceHandler.swift`:
- [BLOCKING] packages/swift-sdk/Sources/SwiftDashSDK/PlatformWallet/PlatformWalletPersistenceHandler.swift:3024-3034: Wallet deletion PHASE 1 omits PersistentDashpayPayment children — same fatal pattern as contactRequests
  PHASE 1 iterates `dpnsNames`, `dashpayProfile`, and `contactRequests` but NOT `dashpayPayments`. `PersistentDashpayPayment.owner` is non-optional and `PersistentIdentity.dashpayPayments` is the cascading inverse added in this PR. The surrounding comment (lines 3008-3023) explicitly documents that this phase exists because SwiftData fatals during `save()` when it must null out a non-optional inverse on a child processed in the same batch — exactly the shape of the new payments relationship. A wallet with persisted DashPay payment history will hit the SwiftData fatal at PHASE 2 `save()`, aborting before the wallet row is removed. The user believes their data was wiped; plaintext memo + counterparty id + amount + txid rows remain on disk. Pre-delete `identity.dashpayPayments` alongside the other children.

pub unsafe extern "C" fn established_contact_get_note(
    contact_handle: Handle,
    out_note: *mut *mut std::os::raw::c_char,
) -> PlatformWalletFFIResult {
    check_ptr!(out_note);
    *out_note = std::ptr::null_mut();

    let option =
        ESTABLISHED_CONTACT_STORAGE.with_item(contact_handle, |contact| contact.note.clone());
    let option = unwrap_option_or_return!(option);
    let note = unwrap_option_or_return!(option);
    let c_str = unwrap_result_or_return!(std::ffi::CString::new(note));
    unsafe { *out_note = c_str.into_raw() };
    PlatformWalletFFIResult::ok()
}

let proof: Option<Vec<u8>> = if auto_accept_proof.is_null() || auto_accept_proof_len == 0 {
        None
    } else {
        if !(38..=102).contains(&auto_accept_proof_len) {
            return PlatformWalletFFIResult::err(
                PlatformWalletFFIResultCode::ErrorInvalidParameter,
                format!(
                    "autoAcceptProof must be 38-102 bytes, got {}",
                    auto_accept_proof_len
                ),
            );
        }
        Some(std::slice::from_raw_parts(auto_accept_proof, auto_accept_proof_len).to_vec())
    };

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

- [BLOCKING] In `packages/rs-platform-wallet/src/wallet/identity/network/profile.rs`:752-766: Contact-profile chunk query omits orderBy required for $ownerId In
  `fetch_contact_profiles_chunk` builds a `$ownerId In [chunk]` query but leaves `order_by_clauses: vec![]` at line 763. `In` is a range operator and DAPI rejects the request with 'missing order by for range error' — every contact-profile chunk fails and is skipped, so the new contact-profile cache/UI never receives remote profiles. The PR's own commit `82c85220ff` documents this as a known bug but has not fixed it. Since this PR ships the contact-profile sync feature that the new SwiftUI Requests tab depends on, the fix is a prerequisite, not a follow-up. Add an `OrderClause { field: "$ownerId", ascending: true }` to `order_by_clauses` (importing `OrderClause` from `dash_sdk::drive::query`).
- [SUGGESTION] In `packages/rs-platform-wallet-ffi/src/established_contact.rs`:156-169: established_contact_get_note leaves *out_note undefined on early-return paths
  Sibling `established_contact_get_alias` (103-117) writes `*out_alias = std::ptr::null_mut()` immediately after `check_ptr!`, establishing the module's C-ABI contract that out-params are defined-null on early returns. `established_contact_get_note` skips this pre-null write at line 160. Early returns from `unwrap_option_or_return!` (storage NotFound or `contact.note == None`) and `unwrap_result_or_return!` (CString::new failure on interior NUL — reachable from counterparty-controlled note content via `established_contact_set_note`) leave `*out_note` indeterminate across the ABI. A caller that doesn't pre-zero the slot can read a stale pointer or pass it to `platform_wallet_string_free`, risking invalid-free or double-free. One-line fix matches the sibling pattern exactly.
- [SUGGESTION] In `packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Views/DashPay/ContactRequestsView.swift`:119-129: Pending incoming-request rows fetch attacker-controlled avatar URLs before user consent
  `sync_contact_profiles` (profile.rs:642) includes `managed.incoming_contact_requests.keys()` in the per-owner fetch plan, populating the contact-profile cache for senders the victim has never accepted. `IncomingRequestRow` feeds `cachedProfile(row.contactIdentityId)?.avatarUrl` into `DashPayAvatarView` → SwiftUI `AsyncImage`, issuing an outbound HTTPS GET to the sender-controlled host on first render — leaking IP, online state, TLS/UA fingerprint, and per-victim URL-token receipt confirmation before any consent action. With `PersistentDashpayContactProfile` SwiftData persistence the channel survives restart; `is_valid_avatar_url` only validates scheme/length. Ignore mutes only after first render. Either suppress remote avatars Swift-side for unaccepted senders (initials-only variant for the Requests tab) or strip `avatarUrl` from the Rust→Swift projection until the sender becomes an established contact.
- [SUGGESTION] In `packages/rs-platform-wallet-ffi/src/dashpay_profile.rs`:90-185: DashPay profile reader trio leaves *out_profile / *out_has_profile undefined on early-return paths
  `managed_identity_get_dashpay_profile`, `platform_wallet_get_dashpay_profile`, and `platform_wallet_get_contact_profile` only assign `*out_profile` / `*out_has_profile` inside the Some/None match arms. After `check_ptr!`, early returns from `unwrap_result_or_return!(read_identifier(..))` and `unwrap_option_or_return!` (handle NotFound, missing managed identity, missing contact entry) leave both out-pointers indeterminate. `DashPayProfileFFI` owns `*mut c_char` fields released by `dashpay_profile_ffi_free` — a subsequent free on a slot the caller didn't pre-zero would free garbage pointers across the ABI. Pre-write `*out_profile = DashPayProfileFFI::empty(); *out_has_profile = false;` immediately after `check_ptr!` in each function, matching the `established_contact_get_alias` precedent and the explicit empty-construction already used in the None match arms.
- [SUGGESTION] In `packages/rs-platform-wallet-ffi/src/persistence.rs`:2125-2133: FFI get_core_tx_record drops InstantSend rows, defeating reconcile_sent_payments recovery on Swift backend
  `context_kind == 1` still hard-returns `Ok(None)` with the IS-lock-not-persisted rationale. `reconcile_sent_payments` treats `TransactionContext::InstantSend` as final for DashPay display and uses persisted core records to recover Pending Sent entries; this adapter discards them before reconcile sees them. The relaunch-after-IS-lock-but-before-block recovery case therefore remains Pending forever on iOS. The Rust unit tests inject `TransactionContext::InstantSend` through a custom persister and bypass this fallback. Either reconstruct a synthetic `TransactionContext::InstantSend(IsdLock::default())` at this boundary when tx bytes are present, or expose a separate adapter that returns the IS context without requiring the on-disk IS-lock blob.
- [SUGGESTION] In `packages/rs-platform-wallet-ffi/src/identity_persistence.rs`:597-641: Confirmed-absent contact profiles cannot cross the Swift persistence boundary — stale rows resurrect on cold start
  `allocate_contact_profile_rows` continues past entries with `profile == None` ("Skip confirmed-absent entries — the negative cache is not persisted; it rebuilds on the next sweep"). The Rust→Swift FFI projection carries no removal intent for absences; Swift's `upsertDashpayContactProfiles` is append/refresh-only; and `ContactProfileRestoreEntryFFI` rehydrates every persisted row as `ContactProfileEntry { profile: Some(..) }`. When a contact removes their on-chain `dashpay.profile`, `apply_fetched_profile` flips the in-memory entry to None, but the absence is dropped at the FFI projection — the stale `PersistentDashpayContactProfile` row survives on disk. On cold start the cache rehydrates as `Some(stale_profile)` and the UI re-issues GETs to the previously attacker-controlled `avatarUrl`, defeating on-chain removal and compounding the unaccepted-sender avatar-fetch tracking channel. Project absences as an explicit delete intent across the boundary (e.g. `removed_contact_profile_ids: *const [u8;32] + count`), mirroring the `ContactIgnoredSenderFFI` removal-set shape already established on the same callback.
- [SUGGESTION] In `packages/rs-platform-wallet-ffi/src/dashpay.rs`:241-244: autoAcceptProof FFI copies caller-controlled length before enforcing the 38-102 byte contract
  `platform_wallet_send_contact_request_with_signer` accepts `auto_accept_proof` as a raw pointer plus `usize` length and immediately builds a Vec with `from_raw_parts(..., auto_accept_proof_len).to_vec()`. The inner SDK and DashPay docs require proofs in the 38-102 byte range, but that validation happens only after Rust has read and allocated the caller-declared length. With QR-based auto-accept planned for this field, a malformed QR/import path or stale foreign binding can drive an oversized allocation or out-of-bounds read across the FFI boundary before the fixed-size proof contract runs. Reject non-null proofs with `len < 38` or `len > 102` before forming the slice.
- [SUGGESTION] In `packages/rs-platform-wallet-ffi/src/persistence.rs`:1493-1504: Changeset-end callback errors are logged and discarded — Swift rollback is invisible to Rust round_success
  Swift's `endChangeset` catches `backgroundContext.save()` failures and calls `backgroundContext.rollback()`, but the C shim `changesetEndCallback` returns 0 regardless. On the Rust side, lines 1493-1498 only log a non-zero result via `eprintln!` and never flip `round_success` based on the callback's return value. The check at 1500 (`if !round_success`) reacts only to per-kind callback failures recorded earlier in the round, not to the changeset-end outcome. If Swift fails to commit the round and silently rolls back, Rust still considers `store()` successful, merges the changeset into the long-lived `pending` accumulator at 1515-1525, and the staged in-memory state diverges from durable SwiftData state. Either propagate the Swift `save()` outcome through the shim's return code and gate `round_success` on it, or have the Swift handler surface save failures via a separate error-set callback before the round closes.
- [SUGGESTION] In `packages/rs-platform-wallet/src/wallet/identity/network/profile.rs`:588-731: Contact-profile checked_at_ms not durably persisted on unchanged refresh — negative-cache backoff does not survive restart
  `apply_fetched_profile` always refreshes `checked_at_ms = now_ms` in memory but returns `changed` only when the stored profile value differs (equality compares only profile content). `sync_contact_profiles` calls `persister.store` only when `any_changed` is true. A re-check confirming the same present or confirmed-absent profile updates the timestamp in memory only — the FFI persistence callback never fires. After cold start, restored rows carry stale `checked_at_ms`, `should_fetch_profile` immediately re-issues an `In` query for every unchanged contact, and the negative-cache backoff effectively does not survive restart. This amplifies the pre-consent avatar tracking channel and creates a cold-start fetch storm; a failed earlier store is also not retried because later sweeps see `changed = false`. Return a separate `needs_persist` signal from `apply_fetched_profile` for timestamp-only refreshes, with coarse coalescing if write-amp matters.
- [SUGGESTION] In `packages/rs-sdk/src/platform/dashpay/contact_request_queries.rs`:41-112: Paginated retrieve-all has no per-call total or elapsed budget — algorithmic-DoS surface against the recurring sync loop
  `fetch_contact_requests_paginated` drains every matching document at `CONTACT_REQUEST_PAGE_SIZE = 100` per page with no per-call total cap, no elapsed-time budget, and no caller-visible continuation. On cold start, restore-from-seed, or any `after_created_at == None` path it walks the entire history in one call. `unignore_sender` resets `high_water_received_ms` to None, so any UI un-ignore drops the next sweep onto the full retrieve-all. Combined with the recurring `DashPaySyncManager` tick added in this PR, an attacker who spams `contactRequest` documents (varying `accountReference` to defeat per-request dedup) against one of the wallet's identities can make every recurring sweep monopolize the SDK gRPC client and starve every other identity's sync — a cheap algorithmic-DoS against the verified-proof query path. Add a configurable total-document ceiling per sweep with a resumable cursor, or at minimum a logged-warn + early-break above a threshold.

order_by_clauses: vec![dash_sdk::drive::query::OrderClause {
                field: "$ownerId".to_string(),
                ascending: true,
            }],

pub unsafe extern "C" fn established_contact_get_note(
    contact_handle: Handle,
    out_note: *mut *mut std::os::raw::c_char,
) -> PlatformWalletFFIResult {
    check_ptr!(out_note);
    *out_note = std::ptr::null_mut();

    let option =
        ESTABLISHED_CONTACT_STORAGE.with_item(contact_handle, |contact| contact.note.clone());
    let option = unwrap_option_or_return!(option);
    let note = unwrap_option_or_return!(option);
    let c_str = unwrap_result_or_return!(std::ffi::CString::new(note));
    unsafe { *out_note = c_str.into_raw() };
    PlatformWalletFFIResult::ok()
}

let proof: Option<Vec<u8>> = if auto_accept_proof.is_null() || auto_accept_proof_len == 0 {
        None
    } else {
        if !(38..=102).contains(&auto_accept_proof_len) {
            return PlatformWalletFFIResult::err(
                PlatformWalletFFIResultCode::ErrorInvalidParameter,
                format!(
                    "autoAcceptProof must be 38-102 bytes, got {}",
                    auto_accept_proof_len
                ),
            );
        }
        Some(std::slice::from_raw_parts(auto_accept_proof, auto_accept_proof_len).to_vec())
    };

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

- [BLOCKING] In `packages/rs-platform-wallet/src/wallet/identity/network/profile.rs`:752-766: Contact-profile chunk query omits orderBy required for $ownerId In
  Verified at HEAD: `fetch_contact_profiles_chunk` builds a `$ownerId In [chunk]` query at lines 756-760 with `order_by_clauses: vec![]` at line 763. The inline comment at 733-736 ("the `profile` `ownerId` index is unique, so the set lookup proves cleanly with an empty `order_by`") is incorrect — Drive's `WhereOperator::In.is_range()` returns true (packages/rs-drive/src/query/conditions.rs:128-135), and packages/rs-drive/src/query/mod.rs:2166-2171 returns `QuerySyntaxError::MissingOrderByForRange` on any range clause without a matching `order_by` entry, regardless of index uniqueness. Every contact-profile chunk fails on the live network and is swallowed by the per-chunk log-and-continue handler at 718-725, so the contact-profile sync that this PR's SwiftUI Requests/Contacts surface depends on never populates remote profiles. This is a prerequisite for the feature shipping in this PR, not a follow-up. Add `OrderClause { field: "$ownerId".to_string(), ascending: true }` (imported from `dash_sdk::drive::query`) to `order_by_clauses`.
- [SUGGESTION] In `packages/rs-platform-wallet-ffi/src/established_contact.rs`:156-169: established_contact_get_note leaves *out_note undefined on early-return paths
  Sibling `established_contact_get_alias` (103-117) writes `*out_alias = std::ptr::null_mut();` immediately after `check_ptr!` at line 108, establishing the module's C-ABI contract that out-params are defined-null on early returns. `established_contact_get_note` only calls `check_ptr!(out_note)` at line 160 and skips the pre-null write. Early returns from `unwrap_option_or_return!` (storage NotFound, `contact.note == None`) and `unwrap_result_or_return!` (CString::new failure on interior NUL — reachable from counterparty-controlled note content via `established_contact_set_note`) leave `*out_note` indeterminate across the ABI. A caller that doesn't pre-zero the slot can read a stale pointer or pass it to `platform_wallet_string_free`, risking invalid-free or double-free.
- [SUGGESTION] In `packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Views/DashPay/ContactRequestsView.swift`:119-129: Pending incoming-request rows fetch attacker-controlled avatar URLs before user consent
  `sync_contact_profiles` (profile.rs:642) includes `managed.incoming_contact_requests.keys()` in the per-owner fetch plan, populating the contact-profile cache for senders the victim has never accepted. `IncomingRequestRow` feeds `cachedProfile(row.contactIdentityId)?.avatarUrl` into `DashPayAvatarView` → SwiftUI `AsyncImage`, issuing an outbound HTTPS GET to the sender-controlled host on first render — leaking IP, online state, TLS/UA fingerprint, and per-victim URL-token receipt confirmation before any consent action. With the `PersistentDashpayContactProfile` SwiftData persistence introduced by this PR the channel survives restart; Rust-side `is_valid_avatar_url` only validates scheme/length. Ignore mutes only AFTER first render. Either suppress remote avatars Swift-side for unaccepted senders (initials-only variant for the Requests tab) or strip `avatarUrl` from the Rust→Swift projection until the sender becomes an established contact.
- [SUGGESTION] In `packages/rs-platform-wallet-ffi/src/dashpay_profile.rs`:90-185: DashPay profile reader trio leaves *out_profile / *out_has_profile undefined on early-return paths
  `managed_identity_get_dashpay_profile` (90-112), `platform_wallet_get_dashpay_profile` (116-145), and `platform_wallet_get_contact_profile` (153-185) only assign `*out_profile` / `*out_has_profile` inside the Some/None match arms. After `check_ptr!`, early returns from `unwrap_result_or_return!(read_identifier(..))` at lines 125, 163-164 and `unwrap_option_or_return!` (handle NotFound at 100, 132-133, 173) leave both out-pointers indeterminate across the C ABI. `DashPayProfileFFI` owns `*mut c_char` fields released by `dashpay_profile_ffi_free` — a subsequent free on a slot the caller didn't pre-zero would free garbage pointers (invalid-free or double-free). Pre-write `*out_profile = DashPayProfileFFI::empty(); *out_has_profile = false;` immediately after `check_ptr!` in each function, matching the `established_contact_get_alias` precedent and the explicit empty-construction already used in the None match arms.
- [SUGGESTION] In `packages/rs-platform-wallet-ffi/src/persistence.rs`:2125-2133: FFI get_core_tx_record drops InstantSend rows, defeating reconcile_sent_payments recovery on Swift backend
  `context_kind == 1` (InstantSend) at line 2127 hard-returns `Ok(None)` with the IS-lock-not-persisted rationale. `reconcile_sent_payments` treats `TransactionContext::InstantSend` as final for DashPay display and uses persisted core records to recover Pending Sent entries; this Swift→Rust FFI adapter discards them before reconcile sees them. The relaunch-after-IS-lock-but-before-block recovery case therefore remains Pending forever on iOS. The Rust unit tests inject `TransactionContext::InstantSend` through a custom persister and bypass this fallback, so the gap is not exercised in tests. Either reconstruct a synthetic `TransactionContext::InstantSend(IsdLock::default())` at this boundary when tx bytes are present, or expose a separate adapter that returns the IS context without requiring the on-disk IS-lock blob.
- [SUGGESTION] In `packages/rs-platform-wallet-ffi/src/identity_persistence.rs`:597-641: Confirmed-absent contact profiles cannot cross the Swift persistence boundary — stale rows resurrect on cold start
  `allocate_contact_profile_rows` `continue`s past entries with `profile == None` at 610-612 ("Skip confirmed-absent entries — the negative cache is not persisted; it rebuilds on the next sweep"). The Rust→Swift FFI projection carries no removal intent for absences; Swift's `upsertDashpayContactProfiles` is append/refresh-only; and `ContactProfileRestoreEntryFFI` rehydrates every persisted row as `ContactProfileEntry { profile: Some(..) }`. When a contact removes their on-chain `dashpay.profile`, `apply_fetched_profile` flips the in-memory entry to None, but the absence is dropped at the FFI projection — the stale `PersistentDashpayContactProfile` row survives on disk. On cold start the cache rehydrates as `Some(stale_profile)` and the UI re-issues GETs to the previously attacker-controlled `avatarUrl`, defeating on-chain removal and compounding the unaccepted-sender avatar-fetch tracking channel. Project absences as an explicit delete intent across the boundary (e.g. `removed_contact_profile_ids: *const [u8;32] + count`), mirroring the `ContactIgnoredSenderFFI` removal-set shape this PR already establishes on the same callback.
- [SUGGESTION] In `packages/rs-platform-wallet-ffi/src/dashpay.rs`:241-245: autoAcceptProof FFI copies caller-controlled length before enforcing the 38-102 byte contract
  `platform_wallet_send_contact_request_with_signer` accepts `auto_accept_proof` as a raw pointer plus `usize` length and immediately builds a Vec with `std::slice::from_raw_parts(auto_accept_proof, auto_accept_proof_len).to_vec()` at line 244. The inner SDK and DashPay docs require proofs in the 38-102 byte range, but that validation runs only after Rust has read and allocated the caller-declared length. With QR-based auto-accept planned for this field, a malformed QR/import path or stale foreign binding can drive an oversized allocation or out-of-bounds read across the C ABI boundary before the fixed-size proof contract runs. Reject non-null proofs with `len < 38` or `len > 102` at the boundary before forming the slice.
- [SUGGESTION] In `packages/rs-platform-wallet-ffi/src/persistence.rs`:1493-1504: Changeset-end callback errors are logged and discarded — Swift rollback is invisible to Rust round_success
  Swift's `endChangeset` catches `backgroundContext.save()` failures and calls `backgroundContext.rollback()`, but the C shim `changesetEndCallback` returns 0 regardless. On the Rust side, lines 1493-1498 only `eprintln!` a non-zero result and never flip `round_success` based on the callback's return value. The check at 1500 reacts only to per-kind callback failures recorded earlier in the round, not to the changeset-end outcome. If Swift fails to commit the round and silently rolls back, Rust still considers `store()` successful, merges the changeset into the long-lived `pending` accumulator at 1515-1525, and the staged in-memory state diverges from durable SwiftData state. Either propagate the Swift `save()` outcome through the shim's return code and gate `round_success` on it, or have the Swift handler surface save failures via a separate error-set callback before the round closes.
- [SUGGESTION] In `packages/rs-platform-wallet/src/wallet/identity/network/profile.rs`:588-731: Contact-profile checked_at_ms not durably persisted on unchanged refresh — negative-cache backoff does not survive restart
  `apply_fetched_profile` always refreshes `checked_at_ms = now_ms` in memory but returns `changed` only when the stored profile value differs (equality compares only profile content). `sync_contact_profiles` calls `persister.store` only when `any_changed` is true (718-725). A re-check confirming the same present or confirmed-absent profile updates the timestamp in memory only — the FFI persistence callback never fires across the Rust→Swift boundary. After cold start, restored rows carry stale `checked_at_ms`, `should_fetch_profile` immediately re-issues an `In` query for every unchanged contact, and the negative-cache backoff effectively does not survive restart. This amplifies the pre-consent avatar tracking channel and creates a cold-start fetch storm; a failed earlier store is also not retried because later sweeps see `changed = false`. Return a separate `needs_persist` signal from `apply_fetched_profile` for timestamp-only refreshes, with coarse coalescing if write-amp matters.
- [SUGGESTION] In `packages/rs-sdk/src/platform/dashpay/contact_request_queries.rs`:41-112: Paginated retrieve-all has no per-call total or elapsed budget — algorithmic-DoS surface against the recurring sync loop
  `fetch_contact_requests_paginated` drains every matching document at `CONTACT_REQUEST_PAGE_SIZE = 100` per page with no per-call total cap, no elapsed-time budget, and no caller-visible continuation. On cold start, restore-from-seed, or any `after_created_at == None` path it walks the entire history in one call. `unignore_sender` resets `high_water_received_ms` to None, so any UI un-ignore drops the next sweep onto the full retrieve-all. Combined with the recurring `DashPaySyncManager` tick added in this PR, an attacker who spams `contactRequest` documents (varying `accountReference` to defeat per-request dedup) against one of the wallet's identities can make every recurring sweep monopolize the SDK gRPC client and starve every other identity's sync — a cheap algorithmic-DoS against the verified-proof query path. Add a configurable total-document ceiling per sweep with a resumable cursor, or at minimum a logged-warn + early-break above a threshold.

order_by_clauses: vec![dash_sdk::drive::query::OrderClause {
                field: "$ownerId".to_string(),
                ascending: true,
            }],

pub unsafe extern "C" fn established_contact_get_note(
    contact_handle: Handle,
    out_note: *mut *mut std::os::raw::c_char,
) -> PlatformWalletFFIResult {
    check_ptr!(out_note);
    *out_note = std::ptr::null_mut();

    let option =
        ESTABLISHED_CONTACT_STORAGE.with_item(contact_handle, |contact| contact.note.clone());
    let option = unwrap_option_or_return!(option);
    let note = unwrap_option_or_return!(option);
    let c_str = unwrap_result_or_return!(std::ffi::CString::new(note));
    unsafe { *out_note = c_str.into_raw() };
    PlatformWalletFFIResult::ok()
}

let proof: Option<Vec<u8>> = if auto_accept_proof.is_null() || auto_accept_proof_len == 0 {
        None
    } else {
        if !(38..=102).contains(&auto_accept_proof_len) {
            return PlatformWalletFFIResult::err(
                PlatformWalletFFIResultCode::ErrorInvalidParameter,
                format!(
                    "autoAcceptProof must be 38-102 bytes, got {}",
                    auto_accept_proof_len
                ),
            );
        }
        Some(std::slice::from_raw_parts(auto_accept_proof, auto_accept_proof_len).to_vec())
    };

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

- [BLOCKING] In `packages/rs-platform-wallet/src/wallet/identity/network/profile.rs`:752-766: Contact-profile chunk query omits required orderBy
  fetch_contact_profiles_chunk builds a profile query with `$ownerId In [...]` but leaves `order_by_clauses` empty. In Drive, `In` is a range operator, and range clauses require a matching orderBy; the unique ownerId index does not bypass that validation. DAPI rejects this query with the missing-order-by-for-range error, and the caller logs the chunk failure and continues, so the new DashPay contact-profile sync cannot populate remote profiles for the UI.
- [SUGGESTION] In `packages/rs-platform-wallet-ffi/src/established_contact.rs`:156-168: established_contact_get_note leaves out_note undefined on early returns
  The C ABI checks that `out_note` is non-null, then performs fallible storage lookup, option unwrap, and CString construction before writing the output pointer. If any of those paths returns NotFound or an error, callers that did not pre-zero the slot can observe or free a stale pointer. The sibling alias getter already pre-nulls its out-param; this getter should do the same.
- [SUGGESTION] In `packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Views/DashPay/ContactRequestsView.swift`:119-128: Incoming requests load sender-controlled avatars before consent
  The PR's profile sync includes pending incoming request senders, then the Requests screen passes `cachedProfile(row.contactIdentityId)?.avatarUrl` into `IncomingRequestRow`. That row ultimately uses SwiftUI AsyncImage, so an unsolicited sender can publish a per-victim HTTPS avatar URL, send a contact request, and learn when the victim opens the Requests tab before any accept or ignore action. Suppress remote avatars for unaccepted incoming senders, or avoid projecting avatarUrl until the contact is established.
- [SUGGESTION] In `packages/rs-platform-wallet-ffi/src/dashpay_profile.rs`:90-185: DashPay profile getters leave owned out-params undefined
  managed_identity_get_dashpay_profile, platform_wallet_get_dashpay_profile, and platform_wallet_get_contact_profile validate the output pointers but only assign `out_profile` and `out_has_profile` after fallible identifier parsing and handle/storage lookups. Current Swift wrappers often initialize locals first, but the exported C ABI itself should define outputs on every return path because `DashPayProfileFFI` contains owned string pointers later freed by `dashpay_profile_ffi_free`. Initialize `out_profile` to `DashPayProfileFFI::empty()` and `out_has_profile` to false immediately after pointer validation in each function.
- [SUGGESTION] In `packages/rs-platform-wallet-ffi/src/persistence.rs`:2125-2133: InstantSend transaction records are dropped on restore
  Swift persistence returns context kind 1 together with transaction bytes for Mempool/InstantSend rows, but FFIPersister maps `context_kind == 1` to `Ok(None)` before decoding the transaction. The DashPay sent-payment reconciliation path treats InstantSend as display-ready state, so a payment persisted after InstantSend but before a block context can be hidden from Rust after relaunch and remain pending. Return a recoverable context when transaction bytes are present, or expose a separate persisted state that reconciliation can consume without requiring the IS-lock blob.
- [SUGGESTION] In `packages/rs-platform-wallet-ffi/src/identity_persistence.rs`:597-641: Confirmed-absent contact profiles cannot delete persisted rows
  Rust represents a confirmed profile absence as `ContactProfileEntry { profile: None }`, but allocate_contact_profile_rows skips those entries entirely. The Swift side only upserts present profiles, and restore rehydrates every persisted contact-profile row as present. If a contact removes their on-chain DashPay profile, the stale persisted profile, including any old avatar URL, survives on disk and reappears after cold start. Project explicit delete/removal intents across the FFI boundary.
- [SUGGESTION] In `packages/rs-platform-wallet-ffi/src/dashpay.rs`:241-245: autoAcceptProof is copied before validating the proof size
  platform_wallet_send_contact_request_with_signer accepts a raw pointer plus length and immediately reads `auto_accept_proof_len` bytes into a Vec. The DashPay proof contract is 38-102 bytes, but that validation happens after Rust has already trusted the foreign length. A malformed binding or import path can trigger oversized allocation or an out-of-bounds FFI read before the proof is rejected.
- [SUGGESTION] In `packages/rs-platform-wallet-ffi/src/persistence.rs`:1493-1504: changeset-end callback failure is not propagated
  The per-kind persistence callbacks set `round_success = false` on failure, but the final `on_changeset_end_fn` result is only logged. If the Swift side fails to commit or rolls back during changeset end, Rust still sees `round_success == true`, returns success, and merges the changeset into the long-lived pending accumulator. Treat a non-zero changeset-end result as a failed round before the success check.
- [SUGGESTION] In `packages/rs-platform-wallet/src/wallet/identity/network/profile.rs`:588-731: Profile refresh timestamps are not persisted when content is unchanged
  apply_fetched_profile refreshes `checked_at_ms` in memory on every successful fetch, but returns true only when profile content changes. sync_contact_profiles persists only when `any_changed` is true, so unchanged present profiles and confirmed-absent negative-cache refreshes never update durable SwiftData state. After restart, stale checkedAtMs values are restored and the client can refetch immediately, defeating the refresh window and negative-cache backoff across cold starts.
- [SUGGESTION] In `packages/rs-sdk/src/platform/dashpay/contact_request_queries.rs`:41-112: Contact-request pagination has no per-sweep budget
  fetch_contact_requests_paginated drains every matching contactRequest page until exhaustion, accumulating all documents in memory and returning no continuation to the caller. A spammed identity can force cold-start, restore, or recurring DashPay sync to spend an unbounded amount of time and proof verification work in one sweep. Add a per-sweep document or elapsed-time cap with a resumable cursor, or at minimum stop and warn above a defensive threshold.

        order_by_clauses: vec![dash_sdk::drive::query::OrderClause {
                field: "$ownerId".to_string(),
                ascending: true,
            }],

pub unsafe extern "C" fn established_contact_get_note(
    contact_handle: Handle,
    out_note: *mut *mut std::os::raw::c_char,
) -> PlatformWalletFFIResult {
    check_ptr!(out_note);
    *out_note = std::ptr::null_mut();

    let option =
        ESTABLISHED_CONTACT_STORAGE.with_item(contact_handle, |contact| contact.note.clone());
    let option = unwrap_option_or_return!(option);
    let note = unwrap_option_or_return!(option);
    let c_str = unwrap_result_or_return!(std::ffi::CString::new(note));
    unsafe { *out_note = c_str.into_raw() };
    PlatformWalletFFIResult::ok()
}

    let proof: Option<Vec<u8>> = if auto_accept_proof.is_null() || auto_accept_proof_len == 0 {
        None
    } else {
        if !(38..=102).contains(&auto_accept_proof_len) {
            return PlatformWalletFFIResult::err(
                PlatformWalletFFIResultCode::ErrorInvalidParameter,
                format!(
                    "autoAcceptProof must be 38-102 bytes, got {}",
                    auto_accept_proof_len
                ),
            );
        }
        Some(std::slice::from_raw_parts(auto_accept_proof, auto_accept_proof_len).to_vec())
    };

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

- [BLOCKING] In `packages/rs-platform-wallet/src/wallet/identity/network/profile.rs`:752-766: Contact-profile chunk query omits required orderBy for In clause
  fetch_contact_profiles_chunk builds `$ownerId In [...]` with `order_by_clauses: vec![]`. Drive treats `In` as a range operator and requires a matching orderBy — the unique ownerId index does not bypass that validation, so DAPI rejects the query with the missing-order-by-for-range error. The caller logs the chunk failure and continues, so the new DashPay contact-profile sync silently fails for every owner and the UI never gets remote profiles. Add an ascending `$ownerId` order clause.
- [SUGGESTION] In `packages/rs-platform-wallet-ffi/src/established_contact.rs`:156-169: established_contact_get_note leaves out_note undefined on early returns
  The C ABI validates that `out_note` is non-null, then performs fallible storage lookup, option unwrap, and CString construction before writing the output pointer. NotFound, no-note, or interior-NUL paths return without defining `*out_note`, so a foreign caller that did not pre-zero the slot can read or free a stale pointer through `platform_wallet_string_free`. The sibling alias getter already pre-nulls its out-param; this getter should match.
- [SUGGESTION] In `packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Views/DashPay/ContactRequestsView.swift`:119-128: Incoming requests load sender-controlled avatars before consent
  sync_contact_profiles fetches profiles for `managed.incoming_contact_requests.keys()` (profile.rs:640-642), and ContactRequestsView passes `cachedProfile(row.contactIdentityId)?.avatarUrl` into IncomingRequestRow / DashPayAvatarView, which loads via SwiftUI AsyncImage. An unsolicited sender can publish a per-victim HTTPS avatar URL, send a contact request, and learn when the victim opens the Requests tab from the outbound image fetch — before any accept/ignore action. Suppress remote avatar URLs for pending incoming senders, or drop avatarUrl from the Rust→Swift projection until the contact is established.
- [SUGGESTION] In `packages/rs-platform-wallet-ffi/src/dashpay_profile.rs`:90-185: DashPay profile getters leave owned out-params undefined on early returns
  managed_identity_get_dashpay_profile, platform_wallet_get_dashpay_profile, and platform_wallet_get_contact_profile validate `out_profile`/`out_has_profile` but only assign them after fallible identifier parsing and handle/storage lookups. DashPayProfileFFI contains owned C string pointers later released by dashpay_profile_ffi_free, so a foreign caller that reuses an uninitialized slot can free garbage or stale pointers when a NotFound path fires. Initialize `*out_profile = DashPayProfileFFI::empty()` and `*out_has_profile = false` immediately after pointer validation in all three functions.
- [SUGGESTION] In `packages/rs-platform-wallet-ffi/src/persistence.rs`:2125-2133: InstantSend transaction records are dropped on restore
  Swift PlatformWalletPersistenceHandler.getCoreTxRecordCallback returns context kind 1 along with transaction bytes for InstantSend rows, but FFIPersister maps `context_kind == 1` to `Ok(None)` before decoding them. The DashPay sent-payment reconciliation path treats InstantSend as a display-ready state, so a payment persisted after InstantSend but before any block context disappears across the boundary on relaunch and remains stuck pending. Return a recoverable context when the transaction bytes are present, or expose a separate persisted state reconciliation can consume without the IS-lock blob.
- [SUGGESTION] In `packages/rs-platform-wallet-ffi/src/identity_persistence.rs`:597-641: Confirmed-absent contact profiles cannot delete persisted rows
  `ContactProfileEntry { profile: None }` represents a confirmed absence, but allocate_contact_profile_rows skips those entries entirely (line 610-612). Swift only ever receives present profiles and restore rehydrates every persisted row as `profile: Some(...)`, so if a contact removes their on-chain DashPay profile the stale avatarUrl (potentially attacker-controlled) survives in SwiftData and reappears after cold start, keeping the pre-consent tracking channel alive after the public profile is gone. Project explicit delete/removal intents across the FFI boundary for absent profiles.
- [SUGGESTION] In `packages/rs-platform-wallet-ffi/src/dashpay.rs`:241-245: autoAcceptProof is copied before validating the proof size
  platform_wallet_send_contact_request_with_signer reads `auto_accept_proof_len` bytes into a Vec via `slice::from_raw_parts` before the DashPay proof-size contract (38–102 bytes) is enforced. A malformed binding or import path can trigger oversized allocation or an out-of-bounds FFI read before the proof is rejected. Reject lengths outside 38..=102 before forming the slice.
- [SUGGESTION] In `packages/rs-platform-wallet-ffi/src/persistence.rs`:1493-1504: changeset-end callback failure is not propagated into round_success
  Per-kind callbacks set `round_success = false` on failure, but the final `on_changeset_end_fn` result is only printed to stderr (line 1495-1497). If the Swift commit fails or rolls back during changeset-end, Rust still sees `round_success == true`, returns success, and merges the changeset into its long-lived pending accumulator — durable SwiftData state and Rust in-memory pending state silently diverge. Treat a non-zero changeset-end result as a failed round before the `!round_success` check (and have Swift propagate save failure as a non-zero return).
- [SUGGESTION] In `packages/rs-platform-wallet/src/wallet/identity/network/profile.rs`:588-731: Profile refresh timestamps are not persisted when content is unchanged
  apply_fetched_profile refreshes `checked_at_ms` in memory on every successful fetch but returns `true` only when profile content changes; sync_contact_profiles invokes the persister only when `any_changed` is true. Unchanged present profiles and confirmed-absent negative-cache refreshes never reach SwiftData, so after restart the stale `checkedAtMs` is restored and the client can refetch immediately, defeating both the refresh window and the negative-cache backoff across cold starts. Either return a separate `needs_persist` signal for timestamp-only refreshes or persist on every successful refresh.
- [SUGGESTION] In `packages/rs-sdk/src/platform/dashpay/contact_request_queries.rs`:41-112: Contact-request pagination has no per-sweep budget
  fetch_contact_requests_paginated drains every matching contactRequest page until exhaustion, accumulating all documents in memory and exposing no continuation. ContactRequest documents are public, so a hostile sender can spam a target identity and force cold-start, restore, unignore, or the recurring DashPay sync loop to spend unbounded time and proof-verification work in one sweep, starving other wallet sync. Add a per-sweep document or elapsed-time cap with a resumable cursor (or at minimum a defensive threshold that aborts and warns).

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `packages/rs-platform-wallet-ffi/src/dashpay.rs`:
- [SUGGESTION] packages/rs-platform-wallet-ffi/src/dashpay.rs:241-245: Validate auto_accept_proof length before crossing the FFI boundary
  `platform_wallet_send_contact_request_with_signer` calls `std::slice::from_raw_parts(auto_accept_proof, auto_accept_proof_len).to_vec()` as soon as the pointer is non-null and the length is non-zero. The DashPay proof-size contract (38–102 bytes) is only enforced later inside the SDK, after a full copy. A malformed binding or buggy/hostile caller passing an oversized or inconsistent (ptr, len) pair triggers an oversized allocation or an out-of-bounds FFI read before validation runs. Enforce the size range at the entry point, before constructing the slice, so the boundary stays safe regardless of downstream checks.

In `packages/rs-platform-wallet-ffi/src/persistence.rs`:
- [SUGGESTION] packages/rs-platform-wallet-ffi/src/persistence.rs:1493-1504: Fold on_changeset_end_fn failure into round_success
  Per-kind callbacks correctly set `round_success = false` on failure, but `on_changeset_end_fn`'s non-zero return is only printed via `eprintln!`. If the host's COMMIT for the round fails or rolls back at changeset-end, Rust still observes `round_success == true`, returns `Ok(())`, and merges the in-memory changeset into `pending` — leaving Rust's view of persisted state strictly ahead of what the backing store actually committed. Downgrade `round_success` on a non-zero changeset-end result so the existing `!round_success` branch triggers the rollback path.

In `packages/rs-platform-wallet-ffi/src/established_contact.rs`:
- [SUGGESTION] packages/rs-platform-wallet-ffi/src/established_contact.rs:156-169: Initialize *out_note before fallible work in established_contact_get_note
  `established_contact_get_note` validates `out_note` is non-null, then runs three fallible stages (storage `with_item` → `Option` → `CString::new`) before assigning `*out_note`. Each early return leaves the output pointer untouched. The sibling `established_contact_get_alias` at line 108 already establishes the right contract (`*out_alias = std::ptr::null_mut();` immediately after `check_ptr!`); apply the same one-liner here so a C caller that did not pre-zero its slot cannot observe stale memory and pass it to `platform_wallet_string_free`.

In `packages/rs-platform-wallet-ffi/src/dashpay_profile.rs`:
- [SUGGESTION] packages/rs-platform-wallet-ffi/src/dashpay_profile.rs:88-185: Initialize DashPay profile out-params before fallible work
  `managed_identity_get_dashpay_profile`, `platform_wallet_get_dashpay_profile`, and `platform_wallet_get_contact_profile` all validate `out_profile`/`out_has_profile` with `check_ptr!`, then perform fallible identifier parsing and storage lookups via `unwrap_result_or_return!` / `unwrap_option_or_return!` before assigning. `DashPayProfileFFI` owns four C-string pointers, so a C caller that frees a partially-populated struct on error frees stale or garbage pointers. Write `*out_profile = DashPayProfileFFI::empty(); *out_has_profile = false;` immediately after the null-checks in all three entry points so every error path is deterministic and safe to free.

In `packages/rs-platform-wallet-ffi/src/identity_persistence.rs`:
- [SUGGESTION] packages/rs-platform-wallet-ffi/src/identity_persistence.rs:597-641: Confirmed-absent contact profiles cannot delete persisted Swift rows
  `allocate_contact_profile_rows` `continue`s past every `ContactProfileEntry { profile: None }`, with the rationale that the negative cache rebuilds on the next sweep. But the FFI re-emits the full `contact_profile_rows` array on every persist, and Swift's persistence handler upserts only the rows it received — a previously-present-now-absent contact (someone who deleted their profile, or a now-confirmed absence) is invisible to Swift, so a stale display name / avatar URL row survives restarts indefinitely. Either emit absent entries with an `is_present: false` discriminator so Swift can DELETE, or pair the array with a per-row tombstone list.

In `packages/rs-platform-wallet/src/wallet/identity/network/profile.rs`:
- [SUGGESTION] packages/rs-platform-wallet/src/wallet/identity/network/profile.rs:588-731: Profile refresh timestamps are lost across restart when content is unchanged
  `apply_fetched_profile` refreshes `checked_at_ms` in memory on every successful fetch but returns `true` only when profile *content* changes (line 594 compares profiles, not timestamps). `sync_contact_profiles` invokes the persister only when `any_changed` is true (line 718). Result: unchanged present profiles and confirmed-absent negative-cache refreshes — i.e. the steady-state case — keep their refreshed timestamp only in RAM. After restart the persisted `checked_at_ms` reverts to the last content-changing sweep, so `should_fetch_profile` over-refetches on cold start and re-pulls every cached profile (including unsolicited senders'). Persist on timestamp-only refresh past a debounce, or stamp `checked_at_ms` from a separate per-owner heartbeat row.

In `packages/rs-sdk/src/platform/dashpay/contact_request_queries.rs`:
- [SUGGESTION] packages/rs-sdk/src/platform/dashpay/contact_request_queries.rs:41-111: Contact-request pagination has no per-sweep budget
  `fetch_contact_requests_paginated` drains every page until exhaustion and returns one combined `ContactRequestDocuments` map with no continuation token. ContactRequest documents are public and freely indexable by `toUserId`, so a hostile sender can spam a target identity with cheap throwaway requests and force every cold-start / restore sweep to fetch and hold the entire spam set in memory before any per-row logic runs. With the new 15s `DashPaySyncManager` cadence this becomes a recurring memory-amplification surface. Add a per-sweep page or document budget and surface a continuation cursor so the next sweep resumes instead of re-paginating from scratch.

In `packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Views/DashPay/ContactRequestsView.swift`:
- [SUGGESTION] packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Views/DashPay/ContactRequestsView.swift:119-128: Incoming-request rows fetch sender-controlled avatar URLs before consent
  `sync_contact_profiles` now refreshes profiles for `incoming_contact_requests.keys()` every sweep, and `ContactRequestsView` passes `cachedProfile(row.contactIdentityId)?.avatarUrl` into `IncomingRequestRow` / `DashPayAvatarView`, which loads via SwiftUI `AsyncImage`. An unsolicited contact request therefore triggers an unauthenticated HTTPS GET to a URL the sender chose, before the user has accepted — leaking the recipient's IP and approximate online time and giving the sender a tracking pixel into anyone who opens the Requests tab. The `is_valid_avatar_url` filter only constrains the scheme/extension, not who controls the URL. Suppress the avatar (use the placeholder) or proxy through an allow-list until the request is accepted.